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Sujet: Java et les automatismes 

programmables 

Verbe: Pister 

Complement: Java, technologie 
banalis^e par Internet est en passe 
de penetrer le marche des auto- 
matismes programmables. Points 
falbles et points forts de Java 
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ava, technologie nouvelle bana- 
lisee par Internet via les celebres 
applets chargees dans votre 
browser prefere (Navigator de Netsca- 
pe, Explorer de Microsoft etc.), pene- 
trera peut-etre le marche des automa- 
tismes programmables. Rappelons 
qu*un browser est un interface de navi- 
gation sur Internet alors qu*une applet 
est une petite application importee 
automatiquement a travers le reseau 
pour s'executer dans le browser. 

Le Network Computer (NC) est un 
ordinateur sans disque dur utilisant un 
serveur sur le reseau comme memoire 
de masse. Ce n'est pas de la science- 
fiction dMmaginer que Tingenieur pour- 
ra demain utiliser un NC chez lui pour 
visualiser et regler le processus de pro- 
duction. Cet aspect sera repris dans cet 
article plus dans le detail. 

II convient cependant de garder la tete 
froide et de ne pas ceder a Teffet de 
mode en positionnant Java sur tous les 
creneaux. 

Le milieu industriel est assez conserva- 
teur en terme de technique informa- 
tique. II existe en gros deux publics 
dans le monde des automatismes : 
ringenierie des grands comptes qui sert 
souvent de banc d'essais en terme de 
technologie nouvelle et les petits utili- 
sateurs / installateurs qui acceptent 
facilement les innovations lorsqu'elles 
simplifient le travail. 



Une chose parait acquise, le phenome- 
ne Java a atteint une taille critique. Les 
interets economiques et strategiques en 
jeu laissent penser que le phenomene 
va s^amplifier. 

Cet article indique des voies a explorer 
en terme de faisabilite technique ainsi 
que du point de vue marketing. Qu'est- 
ce que Java peut apporter a I'utilisa- 
teur ? Solutions moins onereuses, 
multi foumisseurs, multi plates- formes, 
ouverture de Tatelier logiciel ? 

La suite de ce papier aborde les sujets 

suivants : 

• les apports techniques de Java, 

• les points faibles de cette technologie, 

• une vision de Tusine integree a 
rintranet entreprise, 

• les impacts potentiels cote atelier 
logiciel et cote application embarquee. 

Principales 
caracteristiques 
DE Java 

Ce langage simple a ete developpe par 
Sun. II est reellement oriente objet 
avec une syntaxe heritee de C/C++, une 
gestion memoire propre (garbage col - 
lector) et le multitaches integre 
(thread). L*unite de compilation est la 
classe d'objet avec une edition de liens 
r^alisee a I'execution (class loader). 

Ce langage est neutre, c'est a dire quMl 
peut s'executer dans nMmporte quel 
environnement pourvu que son executif 
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soit integre dans I'environnement, ce 
qui est le cas dans certains browsers. 
Cet ex6cutif, la Virtual Machine (VM), 
est un processeur logicieL La neutralite 
est due k Tutilisation d*un code inter- 
mediaire, le bytecode, execute par la 
VM. C*est la version bytecode d'une 
applet qui est chargee a travers le 
reseau. 



Java est tres oriente distribution / 
cooperation sur les reseaux via Tinte- 
^1 gration de bon nombre de protocoles 
dans renvironnement de programma- 
fc" tion (TCP/IP, HTTP, FTP etc.)- Java 
O peut aussi faire interagir des objets sur 
I" le reseau via le Remote Method Invoca - 
tion (RMI). Le RMl, c'est la possibilite 
pour un objet d*executer une methode 
d*un objet distant de fagon quasiment 
transparente au niveau applicatif. 

Un browser Java est flexible. II est 
capable, pour dialoguer avec un serveur 
dent il ne connait pas un protocole 
application, de charger en premier le 
driver du protocole avant de dialoguer 
avec le serveur. De meme, il est 
capable, pour interpreter un format de 
donnees inconnu (un fichier graphique 
par exemple), de charger le driver 
dMnterpretation du type de donnees 
avant d'afficher I'image associde au 
fichier. 

Un NC Java est " client-centric 
c'est a dire que Tapplication est exe- 
cutee par Ic NC. En consequence, le 
NC Java est capable de se charger k 
partir d'un Systeme d'Exploitation (SE) 
minimal, de recuperer le reste de son 
SE, un browser et les applications dont 
il a besoin a partir d'un serveur sur le 
reseau. Cette ouverture sur les reseaux 



s*accompagne d*une politique de secu- 
rite grace entre autres au bytecode veri- 
fier qui controle la coherence d*une 
applet avant de Texecuter. 

L^environnement Java est pourvu d'un 
grand nombre de bibliotheques de 
classes structurees en API (Application 
Programming Interface) de base {core 
API) et extension {extension API). 
Citons par exemple la " Java Enterpri- 
se API " qui permet de s'interfacer a 
un serveur SQL et au monde CORBA 
(Common Object Request Broker 
Architecture), 

II faut aussi mentionner le modele de 
composant logiciel identifie sous la 
denomination Java Beans {Bean pour 
grain de cafe). Un Bean est un compo- 
sant logiciel reutilisable qui peut etre 
manipule visuellement dans un outil de 
construction d'application. Son role est 
comparable a celui des controles Acti- 
veX de Microsoft. L'interface d'un 
Bean est standardise, il est facile de les 
faire cooperer. 
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II est possible d'interfacer une appli> 
cation Java avec un autre langage (C, 
C++, assembleur etc.) via la native 
interface pour diverses raisons : perfor- 
mances, utilisation d*une bibliotheque 
graphique existante ... Attention, c'est 
la porte ouverte a la non-portabilite 
d*une application Java. 

Java, c'est aussi un SE complet, le 
JavaOS de Sun, qui permet de suppor- 
ter une application Java sur un proces- 
seur quelconque avec un minimum de 
ressources. C*est le concept de thin 
client que Ton retrouve dans le NC. La 
cible n*a plus a supporter un encom- 
brant Windows NT ou UNIX si toutes 
les applications sont ecntes en Java. 

Ajoutons enfin les processeurs Java 
(pico, micro et ultraJava annonces par 
Sun) qui executeront directement le 
bytecode dans un environnement 
JavaOS. Cette gamme de processeurs 
couvrira les besoins de Tembarque 
avec peu de ressources jusqu*a la sta- 
tion de travail. Sun sort le picoJaval en 
technologic RISK, a 100 Mhz. 

Points faibles de Java 

Java a ete lance il y a deux ans. Malgre 
son developpement tres rapide, il 
manque de maturite, notamment au 
niveau de ses API dont certaines sont en 
cours de specification. II y a risque de 
divergence comme pour le langage C 
ou UNIX avec plusieurs standards en fin 
de course, done des problemes de com- 
patibilite. En particulier, Texistence chez 
Netscape de V Internet Foundation 
Classes (IPC) et chez Microsoft de 
V Application Foundation Classes 
(AFC), declinaisons de I'API graphique 
Java Abstract Window Toolkit (AWT), 
illustre la difTiculte de converger. Cepen- 
dant. Sun met en place le label 100% 
pure Java " afin de certifier les applica- 
tions qui respectent le vrai standard. 

Java est interprete dans les browsers 
avec des performances ne correspon- 
dant pas forcement au besoin de cer- 
taines applications. La technique JIT 
(Just In Time compiler) de compilation 
a la volee permet d'ameliorer les 
choses au prix d*une expansion non 
negligeable du volume de code. Les 
puces Java augmentent les perfor- 
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mances par rapport a la compilation. Nous sommes 
en droit d'esperer que le code Java atteindra les 
performances du C/C-H- au moins dans la version 
silicium. 

La taille memoire utilisee par une application 
Java et son environnement n*est pas negiigeable 
(de I'ordre de plusieurs Mo). Ce n*est pas grave 
pour un PC, pa Test plus pour Tembarque : la defi- 
nition de profits sp^cifiques pour Tembarque est 
une necessite, meme en utilisant le JavaOS. 



Le portage d 'applications de C-h- vers Java indique 
que la consommation memoire augmente tres sensi- 
blement (voir Tarttcle de 01 Informatique du 14 
mars 97: " les defauts de jeunesse de Java : les per- 
formances et la portabilite "). 

Le sujet le plus delicat dans notre domaine d' appli- 
cation est le caractere non " temps reel dur " de 
Java. K. Nielsen, universite de I'lowa et president 
de la societe NewMonics (http.V/www.newmo- 
nics.com), a identifie ces points faibles. Sans entrer 
dans le detail, en voici la liste : le garbage coilec - 
tor (allocation / liberation de la memoire), rordon- 
nancement des taches, la synchronisation des 
taches (risque d'inversion de priorite etc.), le 
manque de moyen d'analyse de Texecution d'une 
application. II propose une API qui est cense 
r^soudre ces problemes. Est-ce le cas ? Y-a-t-il 
d'autres voies ? Le chemin est certainement encore 
long avant de pouvoir programmer temps r6el en 
Java dans un environnement standardise. 

La suite de cet article propose des applications de 
la technologic Java pour les automatismes pro- 
grammables en supposant que les difficultes listees 
ci-dessus sont resolues (tout ou partie), ce qui est 
loin d'etre acquis. 

L'Intranet, 
canal federateur 

DES FLUX D'INFORMATIONDANS 
L'ENTREPRISE 

11 est probable que TCP/IP sur Ethernet devienne 
le reseau federateur de Tusine, de toute Tentre- 
prise, via Tlntranet. Examinons quel serait son 
nouveau positionnement en production. 

L*application d'automatismes est repartie sur les 
reseaux de niveau 0 (capteurs/actionneurs : ASI, 
Seriplex etc.), niveau 1 (peripheric de Pautomatis- 
me : Fip, Profibus etc.) et niveau 3 (supervision : 
TCP/IP sur Ethernet ou autres). 

Si le niveau 0 n*a generalement pas la capacite a 
supporter TCP/IP, il en est autrement du niveau 1 . 
La cohabitation de TCP/IP sur le niveau 1 avec 
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ies protocoles existants (MPS, FMS 
etc.) a de bonnes chances de se concre- 
tiser. N'oublions pas que ce type de 
r6seau doit respecter des contra intes de 
tenue CEM, de determinisme de la 
couche liaison et de temps de reponse 
de l*equipement k une requete. 

L'utilisation de browsers va se genera- 
liser en synergic avec un certain 
nombre de serveurs. L'automatisme 
programmable se doit de supporter 
entre autres TCP/IP pour reussir son 
integration dans I'Tntranet. Nous ver- 
rons certainement dans les annees a 
venir un nombre croissant d'equipe- 
ments connectes k 1* Intranet. Les pro- 
blames de securite sont dtfferents selon 
que Putilisateur connecte k Pautomatis- 
me se trouve sur Tlntranet (securite 
allegee) ou sur Internet (securite plus 
stricte, notamment via la technique du 
firewall ). 

Les impacts potentiels 

COTE atelier LOGICIEL 

Le terme atelier logiciel recouvre I'ate- 

lier de developpement, la console de 

reglage / diagnostic, Tequipement de 

supervision... 

Avant tout, Java est un langage de pro- 
grammation intrinsequement plus pro- 
ductif que C/C++ (gestion memoire 
propre, maquettage etc.). C'est une rai- 
son suffisante pour Putiliser comme 
outil de developpement de Tatelier 
logiciel : le produit sera moins cher ! 

Comme Java est neutre (sauf probleme 
de portabilite en cas d'usage de la nati - 
ve interface)^ Tateiier logiciel est de 
base multi plates-formes. Meme si le 
pare installe est surtout a base de PC 
sous Windows95 / NT, les autres envi- 
ronnements deviennent utilisables. Si 



les utilisateurs nous demandent de faire 
fonctionner tout ou partie de I'atelier 
logiciel sur un NC Java, Top^ration sera 
immediate dans la mesure ou Tatelier 
est deja code en Java. Cet atelier Java 
beneficiera de la technologie Bean 
(modularite, ouverture) et d'un environ- 
nement de pointe tire par les besoins de 
la sphere Intranet / Internet. II est diffi- 
cile aujourd^hui de presager du succes 
des Beans : il se mesurera a la richesse 
des biblioth^ques de composants. 

Reprenons Texemple de Tautomaticien 
equipe d'un NC connecte a T Intranet et 
desireux de regler une variable du pro- 
cessus via un automate programmable. 
Le serveur ayant servi k charger le NC 
pourrait se trouver dans I'automate 
(avec la memoire de masse suffisante) 
ou bien etre localise sur rinternet, 
Dans ce dernier cas, la connexion a un 
site du fournisseur servirait a recu- 
p^rer la derrlere version de I'appli- 
cation qu'il doit utiliser. Ce genre 
d*operation est realisable grace a la 
flexibilite du ^row^er Java. 

Abordons maintenant le domaine de la 
generation de code embarque (qu'il 
s' execute sur un automate de type PC 
ou conventionnel) en supposant les pro- 
blemes temps reels et volume memoire 
resolus. Java apporte la modularite, la 
repartition et un compilateur. Nous 
pouvons imaginer qu'un bloc lECt 131- 
3, un reseau ladder, un grafcet, sera 
genere en code Java avec la classe 
comme granularite. Deux options se 
dessinent. Premi^rement, la cible 
d'execution n'a pas de caracteristiques 
temps reel dur : le module de compila- 
tion par classe avec edition de liens a 
Texecution s'applique. Deuxiemement, 
la cible execute du code dans un envi- 
ronnement plus contraint : si la compi- 



lation teste modulaire, il est preferable 

de faire Tedition de liens dans la fou- 
lee, le resultat etant directement execu- 
table par la cible. 

Pour les utilisateurs informaticiens, il 
serait envisageable d'offrir la possibili- 
te de programmer tout ou partie de 
r application directement en Java, de se 
fabriquer ses Beans. L'utilisation d'un 
langage de script Java, plus simple que 
Java, n*est pas a ccarter. 

Le Bean pourrait servir k structurer 
Papplication, a en faciliter Tecriture 
(composition d'objets graphiques) et 
surtout a faire de la reutilisation. 11 
n'y aurait plus de programmation clas- 
sique, mais de Tassemblage et du para- 
metrage de composants, done reduc- 
tion du cout de Tautomatisme. Qui 
plus est, le fournisseur d'un equipement 
pourrait livrer le Bean approprie pour 
inserer harmonieusement cet equipe^ 
ment dans Papplication d'automatisme. 
Tout ceci passera par de gros efforts de 
standardisation et par la creation d^un 
marche de composants logiciels pour 
Tembarque. 

Les IMPACTS potentiels 

COTE EXECUTION DE L' APPLI- 
CATION d'automatisme 
Le domaine couvert correspond a 
Tautomate en rack, Pautomate PC et 
tous les equipements participants a 
Tautomatisme. II n'est pas interdit 
d*etendre le champ aux machines spe- 
cialisees comme les commandes nume- 
riques, robots... 

L*appIication la plus immediate est le " 
frontal Java '\ c'est a dire un serveur 
Java implemente dans un coupleur de 
communication TCP/IP qui servirait de 
passerelle vers Pautomate afin de pou- 
voir au minimum regler les variables de 
Papplication. C'est facilement reali- 
sable grace a la technique de native 
interface. Une experience similaire a 
ete realisee sur un automate Quantum : 
implementation d'un petit serveur Web 
sans passerelle vers P automate. Elle est 
en cours d 'evaluation sur le Premium. 

Executer du code Java faciliterait la 
cooperation au sein de Papplication 
d*automatisme distribute grace au 
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Remote Method Invocation (RMI). 
C*est egalement Pouverture vers le 
monde CORBA, vers les serveurs de 
base de donnees (SQL ou autres). 
L'utilisation de serveurs dans les auto- 
matismes sera de plus en plus impor- 
tante avec la montee en puissance de 
rintranet. Si Java est adopte par les 
grands foumisseurs d*automatismes, la 
mixite des installations posera motns de 
problemes. 

Pour executer du code Java, il faut 
imptementer la Virtual Machine 
(VM) de preference dans un syst^me 
d'exploitation dedi6 comme JavaOS. 
Pour les performances, utiliser une 
puce Java sera certainement un passa- 
ge oblige. Mettre la VM dans un ASIC 
ne semble pas etre hors de portee, 
gageons que nous verrons un jour sur le 
marche des microprocesseurs clas- 
siques supportant en supplement le 
bytecode. 

Le cout de Tenvironnement d'execu- 
tion Java est le critere permettant de 
positionner la barriere entre Java et la 
technologie actuelle dans Tembarqu^. 
Plus le cout de requipement sera 
eleve, plus il y aura de chances d^uti- 
liser Java : par exemple, une E/S ana- 



logique n*entrera pas dans ce cas de 
figure. 

II se dessine au moins trois tendances 
cote executif Java. La premiere est le 
portage de la VM dans un SE temps 
reel comme Vxworks de WindRiver ou 
Psos de ISI. Dans le cas de Vxworks, la 
VM est executee dans une tache peu 
prioritaire, les taches plus prioritaires 
s'executent de fa^on temps reel. Dans 
cetle solution, le code Java n'est pas 
temps reel. La seconde consiste a utili- 
ser JavaOS en modulant le nombre 
d'API en fonction des besoins (par 
exemple pas de fenetrage). Sur le site 
JavaSoft (http://wwwjavasoft.com), il 
est fait reference a une ** embedded 
API " qui devra deHnir un sous- 
ensemble des API de base pour 
Tembarque. Cette solution aurait le 
merite d'etre standard. Une troisieme 
option, consiste a porter la VM mini- 
male dans un environnement pro- 
prietaire. Une telle experience a 6te 
realisee k Tuniversite de Californie, 
Santa Cruz, avec le " Java Nanokemel 
" (JN) (http://wwwxsc.ucsc.edu/resear- 
ch/embedded/pubs/tr96-29.html). Bien 
que Taspect temps r6el n*ait pas ete pris 
en compte, cette demarche semble pro- 
metteuse pour de petits environnements. 



En CONCLUSION 

Si la penetration de Java dans le deve- 
loppement des applicatifs de Tatelier 
logiciel ne doit pas poser de gros pro* 
blemes, il en est autrement pour le logi- 
ciel embarque. En octobre 96, Sun a 
annonce la creation d'un groupe de tra- 
vail sur la ^Java Automation API" en 
collaboration avec des entreprises du 
metier manufacturier comme ABB Sys- 
tems Control, The Foxboro Company, 
Hewlet-Packard Company, SAP, 
Toshiba Company ... L*objectif est de 
permettre le developpement d* applica- 
tions Java independantes de la plate- 
forme, assurant le controle de proced^ 
temps reel et prenant en compte la 
dimension Intranet et Internet. Les spe- 
cifications sont attendues pour mi-97. 

Si la technologie Java permet de dimi- 
nuer les couts d'installation et de 
maintenance des automatismes ou si 
elle facilite le support de nouvelles 
fonctionnalites comme la connexion 
de Tautomatisme k T Intranet, les four- 
nisseurs ne devraient pas tarder k utili- 
ser Java. I 

Gerard Picon 
Schneider Automation 

Service Logiciel Interface et Application 
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